The IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks. IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session.
The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals. The Session Description Protocol (SDP), carried by SIP signals, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, the IMS allows operators and service providers to control user access to services and to charge users accordingly.
FIG. 1 illustrates schematically how the IMS fits into the mobile network architecture in the case of a General Packet Radio Service (GPRS) access network. As shown in FIG. 1, a control of communications occurs at three layers (or planes). The lowest layer is the Connectivity Layer 1, also referred to as the bearer plane and through which signals are directed to/from user devices accessing the network. The entities within the connectivity layer 1 that connect an IMS subscriber to IMS services form a network that is referred to as the IP-Connectivity Access Network, IP-CAN. The GPRS network includes various GPRS Support Nodes (GSNs). A gateway GPRS support node (GGSN) 2 acts as an interface between the GPRS backbone network and other networks (radio network and the IMS network). The middle layer is the Control Layer 4, and at the top is the Application Layer 6.
The IMS 3 includes a core network 3a, which operates over the middle, Control Layer 4 and the Connectivity Layer 1, and a Service Network 3b. The IMS core network 3a includes nodes that send/receive signals to/from the GPRS network via the GGSN 2a at the Connectivity Layer 1 and network nodes that include Call/Session Control Functions (CSCFs) 5, which operate as SIP proxies within the IMS in the middle, Control Layer 4. The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the user that the user is subscribed to; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF. The top, Application Layer 6 includes the IMS service network 3b. Application Servers (ASs) 7 are provided for implementing IMS service functionality.
The user device or user equipment (UE) may comprise or represent any device or equipment used for communications over a communications network. Examples of a user device or UE that may be used in certain embodiments of the described network(s) are wireless devices such as mobile phones, terminals, smart phones, portable computing devices such as lap tops, handheld devices, tablets, netbooks, computers, personal digital assistants and other wireless devices that may connect to a communications network, or wired or fixed communication devices such as telephones, computing devices such as desktop computers, set-top boxes, televisions, or other devices that may connect to a communications network.
Communication networks may comprise or represent any network used for communications with user devices or UEs connected to the communications network. Examples of communications networks include, but are not limited to, wireless networks such as the Worldwide Interoperability for Microwave Access (WiMAX), wireless local area networks (WLAN) based on the Institute of Electrical and Electronics Engineers' (IEEE) 802.11 standards e.g. Wi-Fi networks, or Internet Protocol (IP) networks, packet-switched networks or enhanced packet switched networks, IMS networks, or communications networks based on wireless, cellular or satellite technologies such as mobile networks, Global System for Mobile Communications (GSM), Wideband Code Division Multiple Access (W-CDMA), CDMA2000 or Long Term Evolution (LTE)/LTE Advanced mobile networks or any 2nd, 3rd or 4th Generation and beyond communications networks.
Nowadays the Rich Communication Suite 5.1 standard defines two mechanisms to exchange user device capabilities including both basic communication services and applications. IMS basic communication services (IMS CoSe) are identified by an IMS communication service identifier (ICSI), and applications or services are identified by an IMS application reference identifier (IARI). Two mechanisms may be used as a capabilities exchange mechanism, the OPTIONS mechanism or the Presence mechanism as outlined in section 6.2 of the RCS 5.1 standard.
Typically user devices publish their capabilities towards a capabilities exchange application server (e.g. CX-AS) in the communication network, which acts as a store of the capabilities for each user device. User devices may then subscribe with the CX-AS to receive the capabilities of other user devices in the network, which allows user devices to receive the capabilities of other user devices in the network for use when the user devices wish to communicate with each other using various application and services. The capabilities and capability notifications may be based on the Extensible Mark-up Language (XML), in which capabilities are defined using elements and attributes that are indicated in an XML document using tags etc. Further information on the capabilities exchange mechanisms for IMS, MMTel, RCS, and capability exchange may be found in RFC 3841, “Caller Preferences for the Session Initiation Protocol (SIP)”, http://tools.ietf.org/html/rfc3841, or RCS 5.1 Services and Client Specification, version 2.0, which are herein incorporated by reference.
IMS (e.g. RCS, Voice over LTE) supports multi-devices per user and multi-service subscriptions. Users can a multitude of multimedia enabled user devices (e.g. work smartphone(s), home smart phone(s), TVs, laptops etc.) attached to their user subscription. Depending on user behaviour (e.g. a user is registered/attached with a number of their user devices simultaneously), IMS controlled services may fork to all user devices and the user will receive service request(s), incoming requests, or calls, etc. on all registered user devices. Currently in an IMS multi-service deployment (e.g. MMTel, RCS with presence etc.) typically all user devices associated with a subscription and registered in the network will receive incoming service requests from the various services available, which can be an amalgamation/mixture of communication services such as, by way of example only, MMTel, video, Presence, Chat services etc.
Mechanisms exist in MMTel via Ut to change the calling preference per device (e.g. “Flexible Communication Distribution in MMTel Application Server (MTAS)”, 1/155 17-CNA 403 9026 Uen). However these calling preference settings are only relevant for specific services on MTAS (e.g. Ut terminated in XDMS in MMTel AS). They are not relevant for other services hosted on other application servers or applications. For a user with multiple devices associated with the user's subscription such as a multi-service subscription, this can lead to a cumbersome user experience as described and illustrated with reference to FIG. 2.
FIG. 2 is a schematic illustration of a communication network 200 including an MMTel/IMS Core 201 for providing network access to several user devices, i.e. a first, second and third user device 202a, 202b and 202c (e.g. mobile phone, laptop, TV) associated with user 203. The communications network 200 also includes a remote end or originating side 204 of the network from which other users (not shown) may originate calls or service requests associated with user 203 and one of the user devices 202a-202c. In this example, user 203 has several user devices 202a, 202b and 202c registered at home and has several services available (e.g. MMTel voice & video, presence etc.) The FCD service in the MMTel AS of the MMTeL/IMS Core 201 allows the caller preference per user device 202a-202c to be changed, which allows the user 203 to allocate a preferred user device that will “ring” first.
For example, the user 203 may wish to allocate the second user device 202b (e.g. their laptop) as the “primary device” on which all incoming service requests or calls are to be received. This is because the user 203 is at home and the family may be watching or using the third user device 202c (e.g. TV) and it would not be optimal that the third user device 202c receives all incoming service requests. By using Ut and the FCD service in the MMTel AS the caller preference per device 202a-202c can be configured to ring the second user device 202b (e.g. laptop) first and then the remaining user devices 202a and 202c if the second user device 202b does not answer. As a specific setting request was sent to a specific service in an AS the user 203 will now receive all MMTel related services (e.g. MMTel voice & video) on the second user device 202b (e.g. laptop) first. However all other services will still be forked to all other registered user devices 202a and 202c (e.g. the mobile telephone and the TV). For example, all presence related requests may be shown on the third user device 202c (e.g. TV). FCD allows only some services to send service requests to the primary user device, and is only useful for MMTel AS services. There will still be unavoidable interruptions to the user and other users on the first and third user devices 202a and 202c for the majority of other services that are available.
Basically, FCD is an IMS terminating service allows multiple user devices (or targets) to be alerted (“rings”) either serially or in a parallel fashion based on user configuration rules. The FCD service can ring up to 1 to 10 targets. User configuration rules can specify either a serial or a parallel distribution. The serial distribution calls each of the targets identified in the active rule consecutively until one target answers or all targets have been unsuccessfully attempted. Each communication set-up attempt is limited in duration by an answer timer. Following expiry of the timer the communication set-up attempt is cancelled and the next target identity in the active rule, if any, is attempted. Parallel distribution calls all targets in the active rule at the same time until one target answers or the time allowed for an answer expires. Following answer or timer expiry communication set-up attempts to unanswered targets from which a final response has not been received are cancelled.
It is evident that FCD can result in a large waste of communications resources should the user not answer immediately the first user device. In addition, in a multiple user device scenario, if a user is using another user device in the group of devices (e.g. a TV or computer), then serial and parallel distribution will cause unnecessary interruptions as described with reference to FIG. 2, this leads to a cumbersome user experience.
There are limited mechanisms in current networks such as those based on IMS that allow the user to have some semblance of control over caller preferences to multiple user devices (e.g. for FCD, the group of user devices may be configured to ring in parallel or ring serially). FCD only allows for a limited user control (via the standard Ut interface) for which user device should initially receive MMTel sessions/service requests etc. The FCD configuration options are only supported and relevant to specific services on a specific application server (e.g. the MMTel AS) in the communication network, which needs to store end user configuration options. It is not a network wide setting (i.e. it will not encompass other services). The services and corresponding service requests or calls that are not subject to the FCD user configuration options or changes thereto will all be received on all user devices, even non-primary user devices that are registered in the communication network. There is no simple and convenient solution for users to control which user device should only receive incoming service requests from multiple services, which can be an amalgamation/mixture of communication services such as, by way of example only, MMTel, Presence, Chat services etc.
Although similar or enhance mechanisms (e.g. subscriber self-management interfaces) could be implemented on all relevant application servers providing the end user services (e.g. Presence server, chat server etc.), such a solution will require expensive and complicated multi-server network assisted synchronization. There is a desire to reduce the wastage of communications resources such as signaling waste, reduce the complexity of communications systems and networks, and improve user control and the user experience for users with multi-device and multi-service subscriptions. There is also a desire to allow users to dynamically control the user device(s) in a group of user devices associated with a user subscription that answer incoming requests (e.g. session/service/call request).